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SECTION  1 


INTRODUCTION 


As  part  of  Air  Force  System  Command's  High  Level  Standardization 
Plan,  in.  June  1981  MITRE  conducted  a  survey  of  ongoing  and  upcoming 
embedded  computer  system  acquisitions  at  ESD.  The  survey  was  funded 
by  Program  Element  64740F,  Computer  Resource  Management  Technology. 

The  purpose  of  the  survey  was  to  determine  the  impact  on  ESD  programs 
of  impending  military  standards  defining  computer  Instruction  Set 
Architectures  and  of  policies  mandating  their  use.  At  the  same  time 
the  questionnaire  requested  information  which  might  show  the  impact  of 
a  prior  standard  and  policy  for  the  JOVIAL  programming  language  and  a 
more  recent  standard  and  proposed  policy  for  the  use  of  the  Ada 
programming  language. 

The  responses  to  the  questionnaires  do  not,  in  themselves, 
provide  detailed  information  about  use  of  computer  resources  in  ESD 
programs.  It  was  not  possible  to  carry  out  interviews  to  expand  on 
and  to  validate  the  responses.  Consequently,  the  following  analysis 
should  be  used  to  indicate  general  practices  at  ESD.  Although  the 
numbers  given  are  not  completely  accurate,  they  do  allow  some 
observations  to  be  made  which  may  be  useful  in  shaping  policy  or  in 
planning  future  in-depth  studies. 


BACKGROUND 

Within  the  Air  Force  and  across  DoD  there  is  a  movement  to 
introduce  standards  for  the  acquisition  of  computer  resources  for 
embedded  computer  systems.  These  standards  would  specify  the 
allowable  choices  of  programming  language  and  Instruction  Set 
Architecture  (ISA).  A  MIL-STANDARD  would  define  the  language  or  ISA 
and  a  policy  would  indicate  the  conditions  under  which  the  language  or 
ISA  must  be  used.  Four  such  standards  are  currently  in  existence,  and 
the  accompanying  policy  documents  are  issued  or  in  draft  form.  The 
standards  define  two  Instruction  Set  Architectures,  developed  by  the 
Air  Force  and  by  the  Army  respectively.  The  language  standards  are 
for  JOVIAL,  developed  by  the  Air  Force,  and  Ada*,  developed  on  a 
DoD-wide  basis. 


Ada  is  a  registered  trademark  of  the  U.S.  Department  of  Defense. 
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An  Instruction  Set  Architecture  for  a  computer  defines  its 
behavior  from  the  point  of  view  of  a  machine  language  programmer.  The 
set  of  instructions,  their  format,  and  the  interrupt  structure  are 
included,  but  the  ISA  does  not  define  execution  speed,  internal 
organization  and  the  technology  which  is  used  to  manufacture  it.  In 
other  words,  two  computers  have  the  same  ISA  if  the  same  software  will 
run  on  each  and  produce  the  same  results,  except  for  timing.  The 
computers  may  differ  in  size,  weight,  and  internal  components. 
Standardization  at  the  ISA  level  is  intended  to  allow  compatibility 
among  computers  without  freezing  the  technology  used  to  construct 
them . 


The  Air  Force  intends  to  use  a  single  standard  ISA  for  16-bit 
computers  and  another  standard  ISA  for  32-bit  computers  in  embedded 
computer  systems.  The  advantages  of  these  restrictions  include  the 
reuse  of  support  and  operational  software  among  computers  with  the 
same  ISA;  upgrade  of  hardware  for  a  system  without  replacement  of 
software;  lower  per  unit  cost  because  of  competitive  sources  to 
produce  equivalent  computers;  and  lower  logistics,  maintenance,  and 
training  costs.  The  two  MIL-STANDARDS  for  ISAs  are  MIL-STD-1 75UA 
which  defines  a  16-bit  computer  ISA  now  used  in  Air  Force  avionics 
applications,  and  MIL-STD-1862A  which  defines  a  32-bit  architecture 
called  NEBULA,  which  has  been  under  development  by  the  Army  with  Air 
Force  participation.  NEBULA  defines  a  family  of  computers  ranging 
from  a  minicomputer  to  a  singleboard  machine.  The  NEBULA  architecture 
was  widely  reviewed  by  military,  academic,  and  industry 
representatives.  The  architecture  was  frozen  in  late  1981.  Initial 
implementations  will  undergo  evaluation  in  1983.  Production  of  NEBULA 
computers  for  the  Army  is  not  scheduled  until  1986.  A  draft 
policy,  DODI  3000. 5X,  "Instruction  Set  Architecture  (ISA) 
Standardization  Policy  for  Embedded  Computers",  which  would  mandate 
the  use  of  these  standards,  has  not  been  approved  due  to  both 
government  and  industry  concerns  about  its  effect  on  competition. 

There  are  also  two  standards  with  respect  to  High  Order 
Programming  languages  (HOLs).  The  first  is  MIL-STD  1589B  which 
defines  the  JOVIAL  J73  language.  The  second  is  MIL-STD  1815  which 
defines  the  Ada  programming  language.  For  both  languages,  there  are 
organizations  which  control  changes  to  the  language.  There  are  a 
number  of  policies  which  govern  the  use  of  programming  languages.  At 
the  DoD  level,  DoDD  5000.29,  issued  in  1975,  mandated  the  use  of  HOLs 
instead  of  assembly  language  in  weapon  systems  in  order  to  reduce  life 
cycle  costs.  DoDI  5000.31,  issued  in  1976,  specified  an  interim  list 
of  approved  HOLs  which  might  be  used  for  embedded  computer  systems. 

The  Air  Force  has  long  had  a  policy  for  use  of  JOVIAL,  in  its  various 
iialects.  The  Ada  programming  language  is  the  outcome  of  a  DoD  effort 
*o  select  or  develop  a  single  H0L  for  all  DoD  applications.  The 
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language  Ada  has  been  defined  through  a  series  of  stages  in  which 
there  was  broad  participation  and  review  by  government,  industry,  and 
academia  on  an  international  level.  Along  with  the  Ada  language  is  a 
programming  environment  containing  tools  for  compiling,  testing, 
debugging,  documenting,  and  maintaining  Ada  programs.  The  Ada 
Programming  Support  Environment  (APSE)  is  undergoing  an  initial 
implementation  as  the  Ada  Language  System,  under  Amy  sponsorship. 
Delivery  of  the  initial  system  is  scheduled  for  early  1983.  The  Air 
Force  is  also  sponsoring  an  implementation  of  the  APSE  called  the  Ada 
Integrated  Environment  (AIE),  which  will  support  primarily  the  coding 
and  maintenance  phases  initially.  Application  of  Ada  for  an 
operational  capability  in  an  embedded  computer  system  is  expected  in 
1985.  The  current  Air  Force  policy  directs  J73  for  avionics  and  air 
launched  missile  applications  with  Ada  to  be  the  standard  for  all 
embedded  computer  systems  when  it  is  ready. 


SECTION  2 


RESULTS  OF  THE  SURVEY 


Selected  data  from  the  responses  to  the  questionnaire  have  been 
summarized.  Results  have  been  grouped  to  give  a  picture  of  the  kinds 
of  programs  which  are  represented,  general  impressions  about  the 
results,  specific  data  about  hardware  selection,  and  then  specific 
data  about  software  selection.  Not  all  of  the  information  requested 
by  the  questionnaire  was  supplied  on  each  response,  so  many  of  the 
results  below  are  based  on  the  subset  of  responses  that  supplied  the 
specific  information. 

For  purposes  of  this  survey,  it  is  useful  to  analyze  the 
characteristics  of  major  subsystems  as  well  as  systems.  These 
subsystems  are  often  distinctive  in  function,  in  phase  of  acquisition, 
and  in  choice  of  computer  resources.  Hence,  they  represent  decision 
points  at  which  standard  computer  resources  can  be  or  might  have  been 
considered.  Most  of  the  statistics  and  other  observations  in  this 
paper  will  be  based  on  subsystems,  or  systems  for  those  programs  which 
have  no  subsystems.  The  latter  will  also  be  referred  to  as 
"subsystems"  for  convenience. 


ESD  PROGRAMS  IN  THE  SURVEY 

A  total  of  forty-eight  responses  were  received,  representing 
information  about  thirty  ESD  programs.  Tables  1,  2,  and  3  summarize 
their  characteristics.  The  programs  responding  ranged  from  large  C3 
programs,  consisting  of  many  subsystems  using  different  computers,  to 
systems  buying  many  copies  of  a  single  device,  such  as  a  radio,  within 
which  there  is  a  microprocessor  or  computer.  There  are  airborne, 
mobile  tactical,  strategic,  space,  and  ground-based  systems 
represented.  While  the  largest  category  of  mission  area  designated 
for  the  systems  was  C3 ,  a  wide  diversity  of  other  mission  areas  is 
represented.  Among  these  are  surveillance,  navigation  and  control, 
and  simulation  and  training.  Three-fourths  of  the  programs  were 
described  as  "new  developments"  rather  than  upgrades.  Ninety  percent 
of  the  programs  plan  for  or  use  organic  maintenance  support. 

About  65%  of  the  subsystems  in  the  survey  were  in  phases  of  their 
life  cycle  prior  to  production  or  deployment.  About  42%  of  these 
subsystems,  or  28%  of  the  total  set  responding,  had  not  yet  decided  on 
the  computers  to  be  used  in  Full  Scale  Engineering  Development.  This 
amounts  to  twelve  pending  decisions  when  the  survey  was  made  about  a 
year  ago.  This  is  a  rough  indicator  of  the  number  of  ESD  programs  in 


a  position  to  adopt  new  standards  in  the  next  several  years.  The 
estimated  number  of  systems  to  be  procured  by  these  twelve  programs  is 
at  least  340. 


GENERAL  IMPRESSIONS 

The  survey  results  deal  with  practices  used  by  ESD  Program 
Offices  in  selecting  computer  hardware  and  software.  In  general, 
these  practices  indicate  that  both  standard  Instruction  Set 
Architectures  and  High  Order  Language  standardization  can  be 
beneficial  to  ESD  programs.  Although  there  is  little  commonality  in 
the  selection  of  computer  hardware  for  ESD  acquisitions,  there  is  a 
surprisingly  large  amount  of  commonality  in  the  choice  of  programming 
language.  There  are  several  possible  explanations.  The  technology 
for  hardware  has  been  improving  much  more  rapidly  than  that  for 
programming  languages.  Each  time  a  computer  is  selected  for  a 
program,  the  choices  of  available  hardware  are  probably  different, 
whereas  the  most  popular  high  order  programming  language  (HOL)  among 
ESD  subsystems  has  been  Fortran,  one  of  the  oldest  HOLs  still  in  use. 
The  choice  of  programming  language  appears  to  be  based  less  on 
capability  than  on  the  availability  of  a  compiler.  The  commonality  of 
programming  language  in  the  absence  of  common  computer  hardware  may 
also  indicate  that  the  need  for  a  common  computer  architecture  is 
mitigated  by  a  common  programming  language,  which  can  serve  as  the 
primary  interface  for  programmers  to  a  computer  provided  assembly 
language  is  not  used.  The  language  can  then  mask  ISA  differences 
among  computers  as  long  as  compilers  are  available.  The  survey 
indicated  a  need  for  a  complete  set  of  support  software  by  most 
programs  but  there  is  no  record  to  show  if  this  requirement  was  mef 


HARDWARE  SELECTION 

A  1980  GAO  study  cited  the  proliferation  of  different  kinds  of 
computers,  and  stated:  "Most  of  these  computers  were  acquired  on  a 
project-by-project  basis  in  which  military  project  officers  and 
contractors  were  given  the  flexibility  to  independently  select  the 
computers  for  their  particular  tactical  systems."  (1)  This  contention 
is  borne  out  by  the  results  of  the  survey,  as  shown  in  Tables  4  and  5. 
Over  50  different  computer  types  have  been  selected 


(1) 


"The  Department  of 
Military  Computers 
Accounting  Office, 


Defense's  Standardization  Program  for 
-  A  More  Unified  Effort  Is  Needed",  General 
LCD-80-69,  June  1980. 
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by  programs  which  responded.  Of  these,  only  10%  are  used  in  more 
than  one  system,  so  there  is  very  little  commonality  of  computer 
type  among  systems  in  the  survey,  although  in  some  cases  there  are 
computers  which  are  members  of  a  family  of  software-compatible 
computers.  The  maximum  commonality  among  subsystems  is  one  computer 
type  which  is  used  in  three  subsystems  of  the  same  large  program. 

In  addition  to  showing  the  lack  of  commonality  among  programs 
in  choice  of  computer  type,  the  survey  shows  greater  commonality  of 
computer  types  within  a  single  program  or  subsystem  of  a  program. 
These  results  are  summarized  in  Table  5.  For  those  programs  which 
had  made  a  computer  selection,  about  half  have  only  one  type  of 
computer.  At  the  subsystem  level,  about  74%  use  only  one  kind  of 
computer . 

The  survey  also  supports  the  GAO  claim  that  the  choice  of 
computer  was  often  made  by  the  contractor.  There  are  indicators  in 
the  data  that  those  choices  might  be  consistent  with  policies 
requiring  the  use  of  standard  ISAs,  if  such  policies  had  existed. 
Most  of  the  computers  are  commercially  available,  or  have  military 
equivalents;  very  few  are  special  purpose.  About  17%  have  military 
nomenclature,  indicating  that  they  are  equivalent  to  military 
standards.  Among  the  two  most  frequent  reasons  given  for  the 
selection  of  the  computers  were  availability  off-the-shelf,  and 
compatibility  with  previously  selected  computers  in  the  same  or 
other  systems  with  which  a  system  must  be  interoperable  (see  Table 
6).  A  policy  on  standard  ISAs  can  provide  greater  compatibility 
among  systems  and  for  upgrades  within  systems.  The  implementation 
of  that  policy  should  also  ensure  the  availability  of  computers  if 
it  is  to  succeed. 

A  strong  motivation  for  the  Army's  support  of  a  standard 
Military  Computer  Family  has  been  the  reduction  of  logistics  support 
costs.  While  there  is  little  data  in  the  survey  results  to  show 
logistics  support  costs,  the  survey  asked  about  the  number  of 
systems  to  be  procured,  and  the  number  of  each  type  of  computer  per 
system.  The  responses  seem  to  be  inconsistent  in  assigning  values 
to  each  answer,  as  there  may  be  one  system  with  many  computers  or 
many  systems  with  one  computer  each,  when  they  ought  to  be 
equivalent.  Furthermore,  the  number  of  systems  was  specified  in 
ranges,  as  shown  in  Tables  7  and  8.  Therefore,  it  is  not  possible 
to  calculate  the  number  of  units  of  each  computer  being  procured. 
Over  half  the  programs  were  buying  ten  or  fewer  systems,  while  96% 
of  the  systems  have  10  or  fewer  computers.  More  than  halt  the 
systems  have  only  one  computer.  The  largest  number  of  units  being 
purchased  for  a  system  was  3,000,  followed  by  800  for  the  next 
largest.  For  this  sample,  one  might  conclude  that  ESD  usually  buys 
a  small  number  of  computers  per  program  or  subsystem.  If  this  is 
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the  case,  it  may  not  continue  to  be  true  as  systems  become 
distributed,  with  collections  of  computers  performing  functions 
previously  executed  in  a  single  computer. 

The  information  from  the  survey  was  not  complete  enough  to 
examine  commonality  in  functional  or  performance  characteristics  of 
the  computers  selected.  However,  it  is  possible  to  distinguish 
computers  by  word  length.  Since  proposed  ISA  standards  provide  for 
a  16-bit  and  a  32-bit  computer,  ESD  programs  can  be  compared  with 
this  aspect  of  the  standards.  Table  9  shows  that  85%  of  the 
computer  types  selected  are  either  16-bit  or  32-bit;  about  62%  were 
16-bit  and  about  23%  were  32-bit.  The  other  choices  ranged  from  8 
bits  to  54  bits.  There  did  not  seem  to  be  any  division  of  word 
length  choices  by  application  area  or  based  on  environmental 
requirements  such  as  mobility  or  weight.  It  appears  likely  that  ESD 
program  requirements  could  be  met  with  the  two  proposed  standard 
word  lengths,  with  the  possible  exception  of  8-bit  microprocessors 
for  some  embedded  applications. 


SOFTWARE  SELECTION 

When  the  DoD  High  Order  Language  standardization  program  was 
formulated  in  1975,  it  was  stated  that  most  embedded  computer  system 
software  was  being  written  in  assembly  language,  and  where  a  HOL  was 
used,  very  large  portions  were  still  written  in  assembly  language 
because  high  order  languages  were  inadequate.  In  many  ways,  the 
results  of  the  survey  for  ESD  programs  contradict  these  claims,  as 
shown  in  Tables  10  and  11.  Perhaps  the  passage  of  time  since  1975 
has  changed  awareness  of  the  importance  of  using  HOLs,  and  the 
issuance  of  Air  Force  and  DoD  policies  requiring  HOLs  has  also 
affected  the  results.  The  information  in  the  survey  does  not  show 
when  the  language  decisions  were  made,  so  it  is  not  possible  to 
assert  that  there  is  a  trend  toward  greater  use  of  HOLs.  What  the 
survey  does  show  is  that  only  one-third  of  the  systems  use  assembly 
language  exclusively.  The  remainder  are  almost  equally  divided 
between  a  mix  of  HOL  and  assembly  language  within  a  subsystem 
(possibly  on  different  machines)  and  exclusively  HOL.  Only  nine 
different  HOLs  are  represented,  five  of  which  are  approved  interim 
languages  in  DoDI  5000.31.  Over  half  the  systems  or  subsystems  use 
one  of  these  interim  languages.  Fortran  is  the  de  facto  HOL 
standard,  used  in  almost  every  system  or  subsystem  which  uses  a  HOL. 
Where  HOL  and  assembly  language  are  both  used,  the  amount  of 
assembly  language  is  surprisingly  small,  as  shown  in  Table  12.  In 
half  the  subsystems  for  which  data  were  provided,  less  than  10% 
assembly  language  was  used  in  combination  with  HOL. 


With  any  policy  mandating  use  of  a  specific  HOL,  one  can  expect 
waivers.  The  questionnaire  asked  whether  JOVIAL  J73  was  required. 
Table  13  shows  the  responses.  Three  fourths  of  the  answers 
indicated  that  J73  was  not  required.  It  is  not  clear  whether 
language  decisions  antedate  the  requirement,  or  some  other  criterion 
was  used.  Of  those  responses  which  said  J73  was  required,  only  25% 
had  not  sought  a  waiver.  However,  only  30%  of  the  waivers  granted 
were  for  use  of  assembly  language.  The  other  70%  all  chose  Fortran 
instead  of  JOVIAL.  The  reasons  for  waivers  were  not  provided  in  the 
survey,  but  generti  reasons  for  language  selection  were  selected 
from  a  list  in  the  questionnaire,  as  shown  in  Table  14.  The  most 
frequent  reason,  given  by  60%  of  the  systems,  was  the  availability 
(or  lack)  of  a  compiler.  The  choice  of  assembly  language  as  well  as 
the  choice  of  Fortran  were  justified  by  compiler  availability.  As 
in  the  case  of  hardware  standardization,  it  appears  that  successful 
adoption  of  a  HOL  standardization  policy  will  depend  on  its  causing 
compilers  to  be  available.  Other  popular  reasons  for  language 
•selection,  cited  by  about  half  the  responses,  were  "suitability  to 
application"  and  "standard  language",  which  are  compatible  with  the 
objectives  of  the  Ada  and  JOVIAL  standardization  efforts.  The 
reasons  for  choice  of  assembly  language  most  often  included 
"processing  requirements"  and  "hardware  selection"  which  might  be 
interpreted  to  mean  the  real-time  performance  requirements  of  an 
application  dictated  the  choice  of  computer,  and  the  unavailability 
of  a  compiler  or  the  assumed  inefficiency  of  compiler-generated  code 
then  dictated  the  use  of  assembly  language. 

It  is  interesting  to  note  the  least  frequently  chosen  reason 
for  selection  of  a  programming  language  as  well  as  the  most 
frequently  chosen  reason.  In  this  survey,  less  than  10%  of  the 
responses  indicated  "maintainability/reliability"  as  a  reason.  One 
can  only  conjecture  that  decisions  made  by  the  developing 
organization  at  the  front  end  of  the  system  life  cycle  tend  to  favor 
minimizing  startup  costs  and  delays  caused  by  compiler  availability, 
rather  than  later  costs  associated  with  system  operation  and 
maintenance.  In  fact,  the  operation  and  maintenance  of  the  system 
are  usually  the  responsibility  of  a  different  organization  than  the 
one  which  makes  the  language  selection.  In  this  survey,  this  is 
confirmed  by  the  frequent  choice  of  language  by  the  developing 
contractor,  while  the  overwhelming  number  of  systems  plan  for  or  use 
organic  maintenance. 


CONCLUSIONS 

Before  imposing  new  standards  for  hardware  and  software 
acquisition,  it  is  desirable  to  determine  what  will  be  the  impact  on 
future  programs.  This  impact  can  be  felt  as  technical  improvements 
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or  deficiencies  caused  by  the  standards.  The  impact  can  also  be 
affected  by  the  reaction  of  Program  Offices  and  the  ways  in  which 
they  change  their  acquisition  practices  or  continue  to  seek  waivers. 

The  responses  to  the  survey  do  not  provide  definitive  answers 
to  questions  about  impact.  They  are  useful  in  showing  what  happens 
when  there  are  no  standards  imposed  for  hardware.  Proliferation  of 
computer  types  has  indeed  resulted  across  programs,  although  the 
number  of  computer  types  within  a  program  is  small.  There  do  not 
seem  to  be  any  serious  technical  impediments  to  adopting  standard 
ISAs.  The  logistics  savings  may  not  be  very  large  if  the  number  of 
units  purchased  is  small,  which  has  been  the  case  in  the  past.  With 
the  increased  use  of  distributed  architectures,  that  may  change. 

The  issue  of  ISA  standardization  should  not  be  considered 
independently  of  language  standardization.  The  survey  indicates  a 
desire  for  commonality  of  HOL  across  programs.  The  use  of  a 
standard  HOL  is  also  preferred.  The  choice  of  HOL  is  dictated  by 
the  availability  of  the  compiler.  This  would  indicate  that 
compilers  must  be  available  whether  or  not  ISAs  are  mandated,  or 
waivers  will  undoubtedly  be  sought  as  they  have  been  for  JOVIAL. 

The  survey  demonstrates  that  the  issue  of  HOL  versus  assembly 
language  is  dying  out  with  the  acceptance  of  HOLs.  A  return  to 
assembly  language  would  probably  occur  if  the  compiled  code  for  Ada 
is  too  inefficient  to  meet  performance  requirements.  Reusability  of 
software  is  not  yet  a  major  consideration  in  language  selection. 
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Table  1 


ESD  Programs  in  the  Survey 


o  Number  of  Programs  Responding  30 

o  Number  of  Subsystems  48 

o  2  of  Subsystems  in  Pre-Production  Phases  “  652 

o  X  of  Pre-Production  Subsystems  which  have 

not  selected  a  computer  ~  422 

o  2  of  subsystems  which  are  new  developments  “  742 

(vs  upgrades) 


Table  2 

Distribution  of  Programs  by  Mission  Area 


102  202  302 


fc* - 

1  Communication 

1  172 

1 

1  Surveillance  and  Warning 

1  142 

1 

1  Intelligence 

1  112 

1 

1  Navigation 

1  102 

1 

1  Control  Radar 

1  72 

1 

1  Simulation  and  Training 

1  72 

1 

1  Weapon 

I  32 

1 

1  Telemetry 

1  32 
_l 
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Table  3 


Program  Maintenance  Concept 


Maintenance  SuDnort 

Z  of  Programs 

Organic 

74Z 

Organic  and  Contractor 

16Z 

Contractor,  then  Organic 

8Z 

Contractor 

2Z 

Table  4 

Commonality  of  Computer  Types  Among  Programs 

Number  of  Ccmputer  Types  ~  50 

Z  of  Computer  Types  Used  in  More  10Z 

thaa  1  Subsystem 
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Table  5 


Commonality  of  Computer  Types  Vithin  Programs  and  Subsystems 


Number  of  Computer  Types 

%  of  Programs 

%  of  Subsystems 

1 

50% 

73.7% 

2 

9.1% 

10.5% 

3 

18.2% 

5.3% 

4 

13.6% 

5.3% 

5 

4.5% 

5.3% 

6 

7 

4.5% 

— - 

Table  6 

Major  Reasons  for  Hardware  Selection 


Reason 

Service  Selected 
Contractor  Selected 
Available  Of f-the-Shelf 
Compatibility 


%  of  Responses* 
9% 

29% 

32% 

21% 


* 

Responders  were  asked  to  fill  in  reasons. 
Answers  are  not  well  defined. 
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Table  7 


Number  of  Systems 

to  be  Procured 

Number 

%  of  ResDonses 

1 

16% 

2-5 

29% 

6-10 

10% 

11-100 

39% 

101-1,000 

4% 

1,001-10,000 

2% 

Table  8 


Quantity  of  Computers  per  System 


Quantity 

1 

2 

3-10 

11-100 

101-1,000 


%  of  Systems 
55% 

23% 

18% 

2% 

2% 


Quantities  are  for  one  type  of  computer 


Table  9 


Distribution  of  Computer  Types  by  Word  Length 


Word 

Length 

(bits)  102  202  302  402  502  602  702 

_ I _ I _ I _ I _ I _ I _ I 


1  16  I 

1  1 

1  32 

1 

I 

1232 

1 

1  36 

1 

1  1  52 

1  1 

1  18 

1  1  42 

1  1 

1  8 

1 

1  1  42 

1  1 

1  54 

1 

1  1  22 

1  ! 

Table  10 

Use  of  H0L  and  Assembly  Language 


Type  of  Language 
Assembly  Language  Only 
HOL  Only 

HOL  and  Assembly 


2  Subsystems 
~  342 
~  282 
~  382 
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Table  11 


Choice  of  High  Order  Language 


Language 

Approved  Standard 
FORTRAN 


%  of  Subsystems 
53% 

48% 

[98%  of  Subsystems  using  HOL] 


According  to  DODI  5000.31 


Table  12 

Percent  of  Assembly  Language  Used  with  HOL 


Ic'k 

Percent  Assembly  Code  %  of.  Subsystems  with  ASM  and  HOL 


1 

9% 

5 

18% 

10 

28% 

20 

9% 

30 

18% 

90 

9% 

95 

9% 

A  small  sample  provided  data 
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Table  13 


JOVIAL  Language  Requirement 


J73  Requirement  not  applicable 
Z  of  Programs  which  received  a  Waiver 
Z  of  Waivers  which  selected  FORTRAN 
Z  of  Waivers  which  selected  Assembly 


75Z  of  Programs 
~  20Z 
70Z 
30% 
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Reasons  for  Language  Selection 


